1. (Field of the Invention)
The present invention relates to a device for task management of in-vehicle electronic control units and a method thereof.
2. (Description of the Related Art)
In a conventional vehicle, overall control of the entire vehicle is realized through distributed processing by electronic control units (ECU) interconnected via an in-vehicle network. In such an in-vehicle network, as a structure to realize a more organic coordination among the electronic control units, introducing remote procedure call (RPC) practically used in the IT field has been considered. The RPC is an interprocess communication protocol for message communications between a client and a server in the client server model in which a received client request (such as a function call) is processed, and the processing result is replied to the client. The RPC is a basic technology of distributed computing.
FIG. 10 shows a model structure of a system in a situation where a message communication function based on the RPC is provided for the vehicle control system. As shown in the figure, ECUs 1 and 2 connected to each other through an in-vehicle network 50 respectively include message communication apparatuses 51, 52. The message communication apparatuses 51, 52 mediate communication of a message (processing request, reply of the processing result thereof or the like) between a client and a server. More specifically, the message communication apparatuses 51, 52 determine the message receiver based on the content of the received message, and sends the message to the message receiver. In reality, functions of the message communication apparatuses 51, 52, clients 53, 54, and a server 55 are respectively realized by software executed on the hardware of the ECU 1 and the ECU 2.
A description will be given of an aspect of a service execution processing in such an in-vehicle control system with reference to the timing chart shown in FIG. 11. In this aspect, the server 55 of the ECU 2 presents service A and service B for the respective clients 53, 54.
As shown in the figure, when the client 54 of the ECU 2 makes a processing request of the foregoing service A, the processing request is sent to the message communication apparatus 52 of the ECU 2. The message communication apparatus 52 performs message receiving processing for upraising (activating) a service for performing the requested processing to upraise the service A presented by the server 55. When the server 55 executes the processing of the upraised service A, the processing result is replied to the client 54 thorough the message communication apparatus 52 again.
Meanwhile, in the figure, slightly after the client 54 makes the processing request of the service A described above, the client 53 of the ECU 1 makes a processing request of the service B. The processing request is firstly received by the message communication apparatus 51 of the ECU 1, and the message receiver is confirmed. After that, the message is sent to the ECU 2. The message communication apparatus 52 of the ECU 2 that receives the message performs message receiving processing to upraise the service B. When the server 55 executes the upraised service B, the processing result is replied to the client 53 thorough the message communication apparatuses 51, 52.
The foregoing service A is executed as a local service call to the server in the ECU same as that of the client. Meanwhile, the foregoing service B is executed as a remote service call to the server in the ECU different from that of the client. However, sending and receiving a message (service processing request, the processing result thereof) between the ECUs is totally responsible for the message communication apparatuses 51, 52, and hidden from the respective clients 53, 54 and the server 55 side. Therefore, the service call can be made regardless of whether local or remote.
When the foregoing communication protocol based on the RPC is employed, the distributed processing system for vehicle control can be easily structured. However, since the following problems therein exist, such a technology is not practically used currently.
In the service execution processing by the message communication function based on the RPC described above, each uprise unit, that is, each task as a unit of reading and executing a processing program is assigned with one service. Tasks are upraised the same number as the number of requested services. Such a structure is effective in order to improve parallel execution characteristics of the functions.
It is demanded of in-vehicle ECUs to be durable for a long time in severe environments such as the environment in the engine room. Thus, compared to general purpose cases, the in-vehicle ECU uses expensive, highly reliable and durable electronic parts, and its setting space is limited. Therefore, the hardware resources thereof are strictly limited. As a result, in the in-vehicle ECU, the overhead in upraising a service (task) such as the memory usage associated with reading a processing program and temporary increase of the CPU load is hardly ignored. When tasks are upraised frequently, the hardware resources are made short, possibly leading to processing stagnation. In the vehicle control system in need of real-time processing, such processing stagnation resulting from lack of resources is crucial.
In the case other than the in-vehicle ECU having the message communication function based on the RPC as described above, processing based on task call may be performed. For example, processing performed commonly by a plurality of controls is managed as a task. Every time the processing is needed, the task is upraised and performed. Thereby, a program code of the common processing is shared to ease the program. However, in this case again, when tasks are upraised frequently, there is a possibility that there is a lack of hardware resources.